
% A more introductory text should come here
Beck and Fowler~\cite[Chapter 3]{refact-book} present 22 bad code smells as indications that there are issues in code that can be solved by refactoring. Among the bad smells they present, one of the most commonly found in practice is \textbf{Duplicate Code}. All the code smells are textually described along with variations of them. For each variation, there are suggestions of refactorings to solve the smell. Wake~\cite{refact-book} presents bad smells by means of a standard format which introduces the smell name, symptoms, causes, and also indicates what to do, payoff, and contraindications. In this paper we have followed a similar structure proposed by Wake. Moreover, Wake classifies code smells in categories according to their relation to classes: they can occur within classes or between classes. In addition, Wake adds six bad code smells to the work by Beck and Fowler.

%book
To our knowledge, the work that closely resembles bad smells for DBC is the book by Mitchell and McKim~\cite{DBC-example-book}. They list \emph{principles} that should be followed by DBC developers for achieving quality contracts. These principles include spatial organization of contracts (by separating queries from commands, or basic from derived queries), better ways to write pre or postconditions (based on query methods) and guidelines for writing effective invariants. We can assume that failure in fulfilling these principles probably results in bad smells. From our catalog, we believe that bad smells like Illogical Contracts and Field Obsession results from lack of similar principles. Regarding the JML models API, previous analysis have found errors in specifications (as the case with JMLObjectSet~\cite{DarvasMueller08}). We believe that bad smells can lead to errors if not tackled during evolution activities.


M\"{a}ntyl\"{a}, Vanhanen, and Lassenius~\cite{mvl03} developed a taxonomy of bad code smells, classifying the 22 code smells proposed by Fowler in 7 higher levels categories, which describe code that has grown so that it cannot be handled, unnecessary code that can be removed,  code that hinder the software modification among other characteristics. Furthermore, they developed an empirical study that provides initial correlation between code smells. They observed in the software that was the study object that, for instance, the \emph{Message Chains} smells correlates with the opposite smell \emph{Middle Man}. A similar study with DBC bad smells would surely bring correlations -- like \emph{Long Specs} and \emph{Illogical Contracts}.

Garcia \textit{et al.}~\cite{gpem09} define \textit{architectural smells} as a commonly used architectural decision that negatively impacts system quality. One of their causes can be the applications of design abstraction at the wrong level of modularity. As an example, the \textit{Scattered Funcionality} smell is related to a system in which multiple components realize the same high-level concern, but some of them also are responsible for orthogonal concerns. This smell indicates a violation of the separation of concern principle. 

Tsantalis, Chaikalis, and Chatzigeorgiou~\cite{tcc08} present the JDeodorant Eclipse plug-in that identifies \textit{Type-Checking} bad smells in Java source code. They present two cases of smells:
in the first, an attribute of a class acts as a type field; in the second case, there is a conditional statement that  casts a reference from a superclass type to the actual subclass 
type in order to invoke methods of such specific subclass. The code smells are removed by application of the refactorings ``Replace Type Code with State/Strategy" and ``Replace Conditional with Polymorphism"~\cite{refact-book}. Following a similar approach, we believe that DBC smells can be automatically detected as well.


Regarding smells that can appear by using languages with modeling purposes, Correa et al.~\cite{cwb07-models} define
OCL~\cite{ocl} \textit{smells} as constructions present in OCL expressions that affect the understandability or maintainability of OCL specifications. The \textit{Implies Chain} OCL \textit{smell}, for example, corresponds to OCL expression in the form \textit{b1 implies (b2 implies b3)} that can be solved by the application of a refactoring \textit{Replace Implies Chain by a Single Implication}.
Other OCL \textit{smells} are associated, for example, to expressions that are bigger than necessary (\textit{Verbose Expression}) or to the use of OCL operations to give the type of objects that the result of an expression depends on (\textit{Type Related Conditionals}). 
These smells are mostly related to our DBC smell \emph{Illogical Contracts}. The authors also presented an experimental study to evaluate the impact of \textit{smells} and refactorings on the understandability of OCL specifications. The study indicated the negative impact of OCL \textit{smells}.
%
% O trabalho seguinte nao estah estritamente relacioado a bad smells em DBC, pois apresenta
% regras de transformacao para expressoes em OCL
%
Cabot and Teniente~\cite{ct07-scp} propose a set of equivalence tranformation rules for OCL expressions.
They do not present OCL \textit{smells} explicitly, but the reason for defining the rules is that
designer may not define constraints the best way according to intents like understandability or efficiency.
%
% Este trabalho relaciona acoplamento de objeto e facilidade de entendimento e modificacao
% de expressoes em OCL.
%
Reynoso \textit{et al.}~\cite{rgpm06-sac} investigate the hypothesis  that strutuctural properties
of OCL expressions  affect understandability and reduces maintainability. They defined a
suite of measures for structural properties of OCL expressions. In particular, they investigated
the relationship between object coupling  in OCL expressions and the understandability and modifiability
of these expressions. They found that the number of classes used in navigations, the number of
collection operations, for instance, influence understandability efficiency. The number and
length of navigations influence modification tasks.  They consider that the results
are an empirical evidence that  coupling defined in OCL expressions by means
of navigations and collection operations is correlated with maintainability of OCL expressions. 




%Concerning Aspect-Oriented Programming, Piveta \textit{et al.}~\cite{piveta-sbes05} adapts bad code smells that occur in object-
%oriented programming to the context of aspect-oriented programming. Similar to our paper, for each bad smell there are suggestion 
%of refactorings that may deal with constructs of object-oriented or aspect-oriented programming. Srivisut and 
%Muenchaisri~\cite{sm07} present new bad smells for aspect-oriented software along with appropriate aspect-oriented
%refactoring methods.










